home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
misc
/
merit
/
1991
/
91_173.txt
< prev
next >
Wrap
Text File
|
1991-05-19
|
37KB
|
1,199 lines
Large Public Data T. Bradley
Networks Working Group C. Brown
Internet Draft Wellfleet Communications, Inc.
A. Malis
BBN Communications
May 17, 1991
Multiprotocol Interconnect
over Frame Relay Networks
1. Status of this Memo
This document proposes an encapsulation method for
transporting network interconnect traffic over a Frame Relay
backbone. Distribution of this document is unlimited. Comments
are welcome.
2. Abstract
This memo describes an encapsulation method for carrying
network interconnect traffic over a Frame Relay backbone. It
covers aspects of both Bridging and Routing.
3. Acknowledgements
Comments and contributions from many sources, especially those
from Ray Samora of Proteon, Ken Rehbehn of Netrix Corporation,
Fred Baker and Charles Carvalho of Advanced Computer
Communications have been incorporated into this document.
Special thanks to Dory Leifer of University of Michigan for
his contributions to the resolution of fragmentation issues.
4. Conventions
The following language conventions are used in the items of
specification in this document:
o Must, Shall or Mandatory -- the item is an absolute
requirement of the specification.
Bradley, Brown, Malis [page 1]
Multiprotocol Interconnect over Frame Relay
o Should or Recommended -- the item should generally be
followed for all but exceptional circumstances.
o May or Optional -- the item is truly optional and may be
followed or ignored according to the needs of the
implementor.
5. Introduction
The following discussion applies to those devices which serve
as end stations (DTEs) on a public or private Frame Relay
network (for example, provided by a common carrier or PTT).
It will not discuss the behavior of those stations that are
considered a part of the Frame Relay network (DCEs).
The Frame Relay network provides a number of Permanent Virtual
Circuits (PVCs) that form the basis for connections between
stations attached to the same Frame Relay network. The
resulting set of interconnected devices forms a private Frame
Relay group which may be either fully interconnected with a
complete "mesh" of PVCs, or only partially interconnected. In
either case, each PVC is uniquely identified at each Frame
Relay interface by a Data Link Connection Identifier (DLCI).
DLCIs have strictly local significance at each Frame Relay
interface, unless the Frame Relay network uses the optional
Global Addressing convention. Because local addressing is
more general, this proposal will concentrate on this form of
addressing and discuss separately possible optimizations for
the global addressing.
6. Frame Format
All protocols must encapsulate their packets within a LAPF-
based frame [1] as required by the Frame Relay
specification[2]. Additionally, packets shall contain
information necessary to identify the protocol carried within
the Protocol Data Unit (PDU), thus allowing the receiver to
properly process the incoming packet. The format shall be as
follows:
Bradley, Brown, Malis [page 2]
Multiprotocol Interconnect over Frame Relay
+-----------------------------+
| LAPD flag (7E hexadecimal) |
+-----------------------------+
| DLCI* . |
+-- . --+
| . |
+-----------------------------+
| Control (UI = 0x03) |
+-----------------------------+
| Optional Pad (0x05) |
+-----------------------------+
| Format Identifier/ |
+-- --+
| Ethertype |
+-----------------------------+
| . |
| . |
| . |
| . |
| Link Protocol Data Unit |
| . |
| . |
+-----------------------------+
| LAPD Frame Check Sequence |
+-- . --+
| (two octets) |
+-----------------------------+
| LAPD flag (7E hexadecimal) |
+-----------------------------+
*DLCIs, as presently defined are 10-bit encoded in
two octets. In some networks DLCIs may, optionally
be increased to three or four octets.
The Control field is either a one or two byte field directly
following the Frame Relay address space (DLCI). Initially
this value shall be a one byte field set to Un-numbered
Information (UI - 0x03). This field is used only for
compatibility with other LAPD networks and has no specific
meaning within the Frame Relay PVC environment at present.
The pad field is an optional octet used to align the packet.
In order to detect its presence or absence, the pad field
Bradley, Brown, Malis [page 3]
Multiprotocol Interconnect over Frame Relay
should be set to 0x05.
The Format Identifier/Ethertype field is a 16-bit value used
to identify the type of frame encapsulated within the PDU.
This is discussed in greater detail in the Interconnect Issues
section.
There is no commonly implemented maximum frame size for Frame
Relay. A network must, however, support at least a 262 octet
maximum. Generally, the maximum will be greater than 1600
bytes, but each Frame Relay service provider will specify an
appropriate value for its network. A Frame Relay DCE,
therefore, must allow the maximum acceptable frame size to be
configurable.
The minimum frame size allowed for Frame Relay is five octets
between the opening and closing flags.
7. Interconnect Issues
There are two basic types of data packets that travel within
the Frame Relay network, routed packets and bridged packets.
These packets have distinct formats and therefore, must
contain an indication that the destination may use to
correctly interpret the contents of the frame. This
indication is embedded within the Format Identifier/Ethertype
field.
In order to allow most protocols to run over frame relay,
there must be a mechanism to allow use of the IEEE 802.2 LLC
header. The additional overhead of including this header,
however, is expensive for small packets (ie telnet traffic).
The Format Identifier/Ethertype (FI/E) field provides the
flexibility to allow either straight ethertype or 802.2 header
encapsulation. If the value of the FI/E field is greater than
or equal to 0x600 it represents an Digital Equipment, Intel,
Xerox (DIX) Ethertype and the PDU will immediately follow. In
this case, the packet will be of the following format:
Bradley, Brown, Malis [page 4]
Multiprotocol Interconnect over Frame Relay
+-------------------------------+
| DLCI | |
+-------------------------------+
|Control = 0x03 | pad = 0x05 |
+-------------------------------+
|Ethertype ( >= 0x600) |
+-------------------------------+
| Protocol packet |
| . |
| . |
| . |
+-------------------------------+
In the case where a 802.2 header is necessary, the value of
the FI/E field is set to 0x0400 and the Frame Relay packet
will be as follows:
+-------------------------------+
| DLCI | |
+-------------------------------+
|Control = 0x03 | pad = 0x05 |
+-------------------------------+
|Format ID 0x400 |
+-------------------------------+
| 802.2 header |
| . |
+-------------------------------+
| Protocol packet |
| . |
| . |
| . |
+-------------------------------+
All stations must be able to accept and properly interpret
both variations of the routed packet encapsulation.
The second type of Frame Relay traffic is bridged packets.
Bridged traffic differs from routed traffic in that the bridge
does not look into the packet to determine the final
destination. Instead, bridges place the MAC header
immediately following the Frame Relay header information and
Bradley, Brown, Malis [page 5]
Multiprotocol Interconnect over Frame Relay
use this to correctly forward the packet. In this case, the
FI/E field indicates, not only that a bridged packet follows
the Frame Relay header, but also some important information
about the packet. The FI/E field is interpreted as follows
for a bridged packet.
+--------------------------------------+
|0 0 0 0 0 0 F Z | Origin media |
+--------------------------------------+
The F bit indicates that the source preserves the FCS within
the packet. If the F bit is set (one), the preserved FCS is
present within the PDU.
The Z bit indicates zero compression. If it is set (one) zero
compression was used. RFC 1220 [11], Point to Point Protocol
Extensions for Bridging, describe algorithms for use of both
the Z and F bits.
The Origin Media field is used to describe on what media the
packet originated. Values used are also included in RFC 1220
[11] listed as MAC type. Specifically, these values are:
MAC Type:
0: Reserved
1: IEEE 802.3/Ethernet
2: IEEE 802.4
3: IEEE 802.5
4: FDDI
other: Assigned by the Internet Assigned Numbers
Authority
A packet bridged over frame relay will, therefore, have the
following format.
Bradley, Brown, Malis [page 6]
Multiprotocol Interconnect over Frame Relay
+-------------------------------+
| DLCI | |
+-------------------------------+
|Control = 0x03 | pad = 0x05 |
+-------------------------------+
| 0000 00FZ | Origin Media |
+-------------------------------+
| MAC Header |
| . |
| . |
+-------------------------------+
| Protocol packet |
| . |
| . |
| . |
+-------------------------------+
In an algorithm form, the format identifier/ethertype field
may be interpreted in the following manner.
if (format_ID >= SMALLEST_ETHERTYPE)
interpret the format_ID as an ethertype
else if (format_ID == 0x0400)
A 802.2 header follows.
else if (format_ID == 0x401)
A fragmented packet; see below.
else if (format_ID < 0x0400)
This is a bridged frame.
perform bridging algorithm
else
Not yet defined; Drop the frame.
8. Logical Link Control - Quality of Service
All Frame Relay stations shall support the Exchange
Identification (XID) Command described in the 802.2 Logical
Link Control (LLC) specification [8]. Using XID, Frame Relay
stations will exchange LLC service information and discover
the level of LLC supported. If both stations of a connection
support LLC2, they may optionally select to use LLC2 and
Bradley, Brown, Malis [page 7]
Multiprotocol Interconnect over Frame Relay
exchange acknowledged packets. This does not imply that both
sides of the connection must use LLC2, or LLC1 exclusively.
As with any use of the XID information, the stations may use
any combination of the supported link control types that is
appropriate for the application.
Frame Relay stations may optionally support the Test Command
also specified in 802.2 LLC standard [8].
9. Fragmentation Issues
Fragmentation allows the exchange of logical frames that are
greater than the maximum frame size supported by the
underlying network. In the case of Frame Relay, the network
may support a maximum as small as 262 octets. Because of this
small maximum size, it is advantageous to support
fragmentation and reassembly.
Unlike other fragmentation procedures, the scope of Frame
Relay fragmentation procedures is limited to the boundry (or
DTEs) of the frame relay network.
The general format of fragmented packets is the same as any
other encapsulated protocol. The most significant difference
being that the fragmented packet will contain the
encapsulation header. That is, a packet is first properly
encapsulated as defined above. Large packets are then broken
up into frames appropriate for the given Frame Relay network
and are encapsulated within the fragmentation format. In this
way, a station receiving fragments may reassemble them and
then put the reassembled packet through the same processing
path as a packet that had not been fragmented.
Fragments are distinguished by the Format ID field of 0x401
and an individual fragment will have the following format.
Bradley, Brown, Malis [page 8]
Multiprotocol Interconnect over Frame Relay
+------------------+------------------+
| DLCI | DLCI |
+------------------+------------------+
| Control 0x03 | Pad 0x05 |
+------------------+------------------+
| Format ID 0x0401 |
+------------------+------------------+
| Fragment sequence number |
+------------------+------------------+
|offset |final|reserved|
+------------------+------------------+
| fragment data |
| . |
| . |
| . |
+------------------+------------------+
| FCS |
+------------------+------------------+
The sequence field is a two octet identifier that is
incremented every time a new complete LPDU is fragmented.
The sequence number allows detection of reversed or lost
frames and prevents erroneous reassembly.
The offset field is a 10 bit value represents the logical
offset of this fragment divided by 32. The first fragment
should have an offset of zero.
The final bit shall be set to 1 on the last fragment and
set to 0 for all other fragments.
The reserved field is not currently defined and must be
set to 0.
Fragments must be sent in order starting with a zero
offset and ending with the final fragment. These
fragments must not be interrupted with other packets or
information intended for the same destination. An end
station must be able to re-assemble up to 2K octets and
is suggested to support up to 8K octet re-assembly.
Bradley, Brown, Malis [page 9]
Multiprotocol Interconnect over Frame Relay
10. Address Resolution
There are situations in which a Frame Relay station may wish
to dynamically resolve a protocol address. Address resolution
may be accomplished using the standard Address Resolution
Protocol (ARP) [3] encapsulated within a Frame Relay packet as
follows:
Ethertype 0x0806 ARP
Data:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type
ar$hln 8 bits Byte length of hardware address (n)
ar$pln 8 bits Byte length of protocol address (m)
ar$op 16 bits Operation code (request or reply)
ar$sha nbytes source hardware address
ar$spa mbytes source protocol address
ar$tha nbytes target hardware address
ar$tpa mbytes target protocol address
ar$hrd - assigned to Frame Relay is 15 decimal
(000F hexadecimal) [4].
ar$pro - see assigned numbers for protocol ID number for
the protocol using ARP. (IP is 2048 decimal ).
ar$hln - length in bytes of the DLCI field. Presently
set to 4 to allow for the expansion to 4 byte
DLCIs.
ar$pln - protocol address length is dependent on the
protocol (ar$pro) (for IP ar$pln is 4).
ar$op - 1 for request and 2 for reply.
If the Frame Relay network provides global addressing, the
hardware address fields will contain the DLCI associated with
the source (ar$sha) and destination (ar$tha) Frame Relay
station. These DLCIs are stored right-justified within the
given field. Any unused upper bits will be set to zero.
Within a locally addressed Frame Relay network, however, DLCIs
do not have a one-to-one mapping. Additionally, an end
Bradley, Brown, Malis [page 10]
Multiprotocol Interconnect over Frame Relay
station does not have an assigned DLCI to put into the ARP
reply. Fortunately, the frame relay network does provide a
method for obtaining the correct DLCIs.
In a locally addressed network, the DLCI carried within the
frame relay header is modified as it traverses the network.
When the packet arrives at its destination, the DLCI is
assigned to the value that, from the standpoint of the
receiving station, corresponds to the sending station. For
example, in figure 1 below, if station A were to send a
message to station B, it would place DLCI 50 in the frame
relay header. When station B received this message, however,
the DLCI would have been modified by the network and would
appear to B as DLCI 70.
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
Figure 1
Lines between stations represent PVC connections.
The numbers indicate the local DLCI associated
with each connection.
Unlike the global addressing case, hardware addresses within
ARP messages in the locally addressed network will be invalid.
The DLCI values found in the frame header will, however, be
Bradley, Brown, Malis [page 11]
Multiprotocol Interconnect over Frame Relay
correct. Though it does violate the purity of layering, Frame
Relay may use the DLCI value in the header as the sender
hardware address. It should also be noted that the target
hardware address, in both ARP request and reply, will also be
invalid. This should not cause problems since ARP does not
rely on these fields and in fact, an implementation may zero
fill or ignore the target hardware address field entirely.
As an example of how this DLCI replacement scheme may work,
refer back to figure 1. If station A (protocol address pA)
wished to resolve the address of station B (protocol address
pB), it would format an ARP request with the following values.
ARP request from A
ar$op 1 (request)
ar$sha unknown
ar$spa pA
ar$tha trying to resolve
ar$tpa pB
Because station A will not have a source DLCI associated with
it, the source hardware address field is not valid.
Therefore, when the ARP packet is received, it must extract
the correct DLCI from the frame relay header and place it in
the source hardware address field. This way, the ARP request
from A will become
ARP request from A as modified by B
ar$op 1 (request)
ar$sha 70 from Frame Relay header
ar$spa pA
ar$tha trying to resolve
ar$tpa pB
Station B's ARP will then be able to store station A's
protocol address and DLCI association correctly. Next,
station B will form a reply message. In many implementations,
ARP simply places the source addresses from the ARP request
into the target addresses and then fills in the source
addresses with its addresses. In this case, the ARP response
would be
Bradley, Brown, Malis [page 12]
Multiprotocol Interconnect over Frame Relay
ARP response from B
ar$op 2 (response)
ar$sha unknown
ar$spa pB
ar$tha 70
ar$tpa pA
Again, the source hardware address is unknown and when the
request is received, station A will extract the DLCI from the
Frame Relay header and place it in the source hardware address
field. Therefore, the response will become
ARP response from B as modified by A
ar$op 2 (response)
ar$sha 50
ar$spa pB
ar$tha 70
ar$tpa pA
Station A will now correctly recognize station B having
protocol address pB associated with DLCI 50.
Reverse ARP (RARP) [5] will work in exactly the same way.
Still using figure 1, if we assume station C is an address
server, the following RARP exchanges will occur.
RARP request from A RARP request as modified by C
ar$op 3 (RARP request) ar$op 3 (RARP request)
ar$sha unknown ar$sha 80
ar$spa trying to resolve ar$spa trying to resolve
ar$tha 60 ar$tha 60
ar$tpa pC ar$tpa pC
Station C will then look up the protocol address corresponding
to DLCI 80 and send the RARP response.
Bradley, Brown, Malis [page 13]
Multiprotocol Interconnect over Frame Relay
RARP response from C RARP response as modified by A
ar$op 4 (RARP response) ar$op 4 (RARP response)
ar$sha ar$sha 60
ar$spa pC ar$spa pC
ar$tha 80 ar$tha 80
ar$tpa pA ar$tpa pA
This means that the Frame Relay interface must only intervene
in the processing of incoming packets. Additionally, a
station on a locally addressed network may learn how others
view it by examining the target hardware address.
In other networks, the ARP request is sent to a well-known
broadcast address. Frame Relay has no such broadcast address.
Some service providers do provide for a multicasting
capability. If this multicasting behaves in such a way that
if a packet is sent via this multicast address, the
destination receives tha packet with a dlci for the source
address (and not the unmodified multicast address), ARP may
use this feature to send requests. ARP requests will use the
multicast address which contains the DLCIs of all reachable
stations (or perhaps the subset of stations to which ARPs are
allowed). This DLCI value must be configurable.
In the case where multicast DLCIs are not available, ARP may
still be implemented. In this case, it is the end station's
responsibility to send a copy of the ARP request through each
available PVC.
In a Frame Relay network that supports the Local Management
Interface (LMI), a Frame Relay end station may use LMI
provided PVC information to dynamically discover its
neighbors. This is accomplished using Inverse ARP (InARP)
[9]. Inverse ARP associates a given hardware address (in this
case a DLCI) with a requested protocol address. Using InARP,
a Frame Relay station may choose to poll end stations on newly
announced PVCs (announced via the LMI status messages) in
order to discover new connectivity. Locally addressed networks
will again need to modify the source hardware address as with
ARP and RARP examples above. The inclusion of InARP support
should be a configurable option.
Bradley, Brown, Malis [page 14]
Multiprotocol Interconnect over Frame Relay
11. IP over Frame Relay
Internet Protocol [7] (IP) datagrams sent over a Frame Relay
network conform to the encapsulation described previously and
can use either the short ethertype or SNAP encapsulation.
Therefore, the IP datagram may be in either of the following
formats:
SNAP encapsulation form of IP over Frame Relay
+---------------------------+---------------------------+
|DLCI* (msb) |DLCI (lsb) |
+---------------------------+---------------------------+
|Control (UI) 0x03 | Pad 0x05 |
+---------------------------+---------------------------+
|FI/E indicating SNAP encapsulation 0x0400 |
+---------------------------+---------------------------+
|DSAP 0xAA |SSAP 0xAA |
+---------------------------+---------------------------+
|LLC control 3 | (three octet) SNAP |
+---------------------------+---------------------------+
|protocol ID or Org code 0 |
+---------------------------+---------------------------+
|Ethertype [4] 0x0800 |
+---------------------------+---------------------------+
| IP Packet |
| . |
| . |
+---------------------------+---------------------------+
Bradley, Brown, Malis [page 15]
Multiprotocol Interconnect over Frame Relay
Ethertype encapsulation form of IP over Frame Relay
+---------------------------+---------------------------+
|DLCI* (msb) |DLCI (lsb) |
+---------------------------+---------------------------+
|Control (UI) 0x03 | Pad 0x05 |
+---------------------------+---------------------------+
|Ethertype [4] 0x0800 |
+---------------------------+---------------------------+
| IP Packet |
| . |
| . |
+---------------------------+---------------------------+
12. Other Protocols over Frame Relay
The IP encapsulation may serve as a model for other protocols
such as ISO, AppleTalk and DECnet. ISO, for example, would
likely use the format identifier field indicating the
existence of a SNAP header and fill in the LSAP appropriately
[4]. An ISO encapsulated frame would also obey ISO 8880-2, ISO
8880-3 and ISO 9577. For example, the frame would be as
follows.
+----------------------+----------------------+
| DLCI | DLCI |
+----------------------+----------------------+
| Control (0x03) | Pad (0x05) |
+----------------------+----------------------+
| Format ID (0x0400 ) |
+----------------------+----------------------+
| IEEE 802.2 LLC1 0xfe | 0xfe |
+----------------------+----------------------+
|NLPID -- ISO 9577 |
+---------------------------------------------+
| ISO data packet |
| . |
| . |
+---------------------------------------------+
Bradley, Brown, Malis [page 16]
Multiprotocol Interconnect over Frame Relay
13. Bridging in a Frame Relay network
A Frame Relay interface acting as a bridge must be able to
flood, forward and filter packets.
Flooding is performed in one of two ways within a Frame Relay
environment. If the Frame Relay service provides multicast
addressing as described above, a flooded packet is simply sent
to the multicast address that includes all accessible end
stations. If the network does not provide multicasting, the
Frame Relay station must send the packet to be flooded on all
available PVCs to simulate the multicast address.
To forward a packet, a bridge must be able to associate a
destination MAC address with a DLCI. It is unreasonable and
perhaps impossible to require bridges to statically configure
an association of every possible destination MAC address with
a PVC. Therefore, Frame Relay bridges must provide enough
information to allow a Frame Relay interface to dynamically
learn about foreign destinations beyond the set of Frame Relay
stations.
To accomplish dynamic learning, a bridged packet shall conform
to the encapsulation described within section 6 and 7 and will
use the Bridged MAC Frame Format Identifier. In this way, the
receiving Frame Relay interface will know to look into the
bridged packet and learn the association between foreign
destination and Frame Relay station. Implementors' note: A
table should be constructed which will grow to include any
number of destination addresses and their associated DLCIs.
This association table will be visible from the Frame Relay
Management Information Base (MIB) [10] and will have the form:
+-----------------------------+
| destination Address | DLCI |
+-----------------------------+
| x.x.x.x | xxxx |
+-----------------------------+
| . | |
| . | |
| . | |
| . | |
+-----------------------------+
Bradley, Brown, Malis [page 17]
Multiprotocol Interconnect over Frame Relay
Using this association table, a Frame Relay interface can
successfully translate the destination MAC address presented
in the forwarded packet with the correct DLCI.
14. References
[1] International Telegraph and Telephone Consultative
Committee, "ISDN User-Network Interface - Data Link
Layer Specification", CCITT Recommendation Q.921,
Fascicle VI.10 IXth Plenary Assembly,
Melbourne, November 1988 ("Blue Book").
[2] American National Standard Institute Telecommunications
Committee, "DSS1 - Core Aspects of Frame Protocol for
Use with Frame Relay Bearer Service", ANSI T1S1/90-214
[3] Plummer, David C., Network Working Group,
"An Ethernet Address Resolution Protocol",
RFC-826, November 1982
[4] Reynolds, J. and Postel, J., "Assigned Numbers",
RFC-1060, ISI, March 1990
[5] Finlayson, Mann, Mogul, Theimer, "A Reverse Address
Resolution Protocol", RFC-903, Stanford University,
June 1984
[6] "Frame Relay Specification With Extensions",
Revision 1.0, Document Number 001-208966, Digital
Equipment Corporation, Northern Telecom, Inc.,
StrataCom, Inc., September 1990
[7] Postel, J. and Reynolds, J., "A Standard for the
Transmission of IP Datagrams over IEEE 802 Networks",
RFC-1042, ISI, February 1988
Bradley, Brown, Malis [page 18]
Multiprotocol Interconnect over Frame Relay
[8] American National Standard, IEEE Standards for Local
Area Networks: Logical Link Control,
802.2-1985 ISO Draft International Standard 8802/2
[9] Inverse Address Resolution Protocol,
Wellfleet Communications draft document
[10] Frame Relay MIB
Wellfleet Communications draft document
[11] Baker, Fred, "Point to Point Protocol Extensions for
Bridging", Point to Point Working Group. RFC-1220
April 1991
15. Authors' Addresses
Terry Bradley
Wellfleet Communications, Inc.
15 Crosby Drive
Bedford, MA 01730
Phone: (617) 275-2400
Email: tbradley@wellfleet.com
Caralyn Brown
Wellfleet Communications, Inc.
15 Crosby Drive
Bedford, MA 01730
Phone: (617) 275-2400
Email: cbrown@wellfleet.com
Bradley, Brown, Malis [page 19]
Multiprotocol Interconnect over Frame Relay
Andrew G. Malis
BBN Communications
150 CambridgePark Drive
Cambridge, MA 02140
Phone: (617) 873-3419
Email: malis@bbn.com
Bradley, Brown, Malis [page 20]
